Skip to content

Deferred loading on autocmd (#event[#pattern])#548

Open
junegunn wants to merge 1 commit intomasterfrom
autocmd
Open

Deferred loading on autocmd (#event[#pattern])#548
junegunn wants to merge 1 commit intomasterfrom
autocmd

Conversation

@junegunn
Copy link
Owner

@junegunn junegunn commented Oct 29, 2016

Does not mean that I'm positive on this. I'm just posting the patch as it was trivial to implement the idea.

Plug 'SirVer/ultisnips',  { 'on': '#InsertEnter' }
Plug 'junegunn/goyo.vim', { 'on': ['Goyo', '#BufEnter#README,BUILD,CHANGELOG'] }

(See :help exists() for #event#pattern syntax)

@junegunn
Deferred loading on autocmd (#event[#pattern])
d7f1846 
e.g.
    Plug 'SirVer/ultisnips',  { 'on': '#InsertEnter' }
    Plug 'junegunn/goyo.vim', { 'on': ['Goyo', '#BufEnter#README'] }
@vheon
Copy link
Contributor

vheon commented Oct 31, 2016

Since which version is the #event#pattern syntax supported? Just asking because you don't seems to have a minimum version of vim for vim-plug and I wouldn't want you to break some users :)

@junegunn
Copy link
Owner Author

junegunn commented Oct 31, 2016

It has been quite some time.

vim/vim@f4cd3e8
vim/vim@a9b1e74

The code in this PR only uses exists('##EventName'). #event#pattern syntax was chosen not to introduce a new, arbitrary syntax, but it's not directly used. The code splits the string.

@vheon
Copy link
Contributor

vheon commented Oct 31, 2016 •
edited
Loading

Thanks for digging that up! 😉 As usual I hope that there is a real use for this other than YCM (I know you get a lots of requests from it).

blueyed
blueyed reviewed Dec 1, 2016
View reviewed changes
plug.vim

function! s:lod_autocmd(name)
call s:lod([a:name], ['ftdetect', 'after/ftdetect', 'plugin', 'after/plugin'])
call s:dobufread([a:name])
Copy link
Contributor

@blueyed blueyed Dec 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be problematic.
I found this PR when looking for a better way to handle custom InsertEnter handling.

I am using the following:

    Plug 'Shougo/deoplete.nvim', {'on': []}
    …
    augroup vimplug_load_on_insertmode
      autocmd!
      autocmd InsertEnter * call plug#load(
            \ 'cursorcross.vim',
            \ 'delimitMate',
            \ 'deoplete.nvim',
            \ ) | call deoplete#enable()
            \ | autocmd! vimplug_load_on_insertmode
    augroup END

And here the call to deoplete#enable() adds a BufEnter autocmd that gets triggered then.
It is a bit weird, since plug#load() should be finished already, before deoplete#enable() then sets up the BufEnter autocmd?! (I have also put it into a separate function to make sure | does not cause it).

Maybe the BufEnter gets queued after the InsertEnter?!

Copy link
Contributor

@blueyed blueyed Dec 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dobufread happens for ftplugin …/.vim/plugged/jedi-vim//**, which is triggered through another handler:

    function s:my_insertenter_python()
      if &ft ==# 'python'
        call plug#load(
            \ 'deoplete-jedi',
            \ 'jedi-vim',
            \ )
        autocmd! vimplug_load_on_insertmode_python
      endif
    endfunction
    augroup vimplug_load_on_insertmode_python
      autocmd!
      autocmd InsertEnter * call s:my_insertenter_python()
    augroup END

Copy link
Contributor

@blueyed blueyed Dec 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this explains the issue: there are two calls to plug#load in that setup.

@blueyed
Copy link
Contributor

blueyed commented Dec 1, 2016

I think this would be good to have.

But for my use case I would need to be able to a) call a custom function afterwards (deoplete#enable()), and b) would like to limit it to a filetypes also (i.e. #InsertEnter, but only for python filetypes).

@blueyed
Copy link
Contributor

blueyed commented Dec 6, 2016

call a custom function afterwards

That is also useful for lazy-loading Unite, so that you can customize it using call unite#custom#source(…) etc.

@junegunn
Copy link
Owner Author

junegunn commented Dec 8, 2016

@blueyed

call a custom function afterwards

vim-plug currently supports that via User autocmd

" Code to execute when the plugin is lazily loaded on demand
Plug 'junegunn/goyo.vim', { 'for': 'markdown' }
autocmd! User goyo.vim echom 'Goyo is now loaded!'

Have you tried it?

b) would like to limit it to a filetypes also (i.e. #InsertEnter, but only for python filetypes).

Hmm, I certainly wouldn't want to go that far. In my opinion, custom autocmd is the answer to such complex use cases.

@blueyed
Copy link
Contributor

blueyed commented Dec 10, 2016

@junegunn

vim-plug currently supports that via User autocmd

Oh, I missed that, sorry. That is nice.
But I wonder if the autocommand name should not have something like a plug_loaded_ prefix?!
Otherwise it could conflict/overlap with a plugin's own custom User autocommand?!

Thanks!

@jbro
Copy link

jbro commented Mar 9, 2017 •
edited
Loading

I think this is a neat little feature, I'm currently using:

Plug 'vim-syntastic/syntastic', { 'on': [] }
"Delay syntatic load until we aren't doing anything
augroup LazySyntatic
  autocmd!
  autocmd CursorHold * :call plug#load('syntastic')
  autocmd CursorHold * :autocmd! LazySyntatic
augroup END

to delay the loading of syntastic. With deferred autoload that could be hidden away with:

Plug 'vim-syntastic/syntastic', { 'on': '#CursorHold' }

@SwenChan
Copy link

SwenChan commented Aug 28, 2019

So, can plug support event now? I'm using SpaceVim which using 'dein' as their default plugin manager and I want to switch to plug , which is my favorite vim plugin manager. But I need this feature because so many plugin in SpaceVim need this.
So, anyone can help with this feature? @junegunn @blueyed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@blueyed blueyed blueyed left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

enhancement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@junegunn @vheon @blueyed @jbro @SwenChan